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1.0 Scope 


This document is a specification of the on-media 
Structure that Is used by Files-11. Files-ll is a general 
Purpose file structure which is intended to be the standard 
File structure for all medium to large PDP-11 systems. 


Small systems such as RT-11 have been specifically excluded 


because the complexity of Files-11 would impose too great a 
burden on their simplicity and small size. 


2.0 Medium 


Files-11 fis a structure which Is imposed on a emedtum. 
That medfum must have certain properties, which are 
described in the following section. Generally speaking, 
block addressable storage devices such as disks and Dectape 
are suitable for Files-11; hence Files-11 structured media 


are generically referred to as disks. 


Zed | Volume 


The basic medium that carries a Files-11_ structure fs 
referred to as a yolume. A volume (also often referred to 


as a unit) is defined as an ordered set of logical blocks. 


A logical blotk Is an array of 512 8-bit bytes. The logical 
blocks in a volume are consecutively numbered from 0 to n= is 


Where the volume contains n logical blocks. The number 


assigned to a logical block. Is called its logical block 
number, or LBN. Flles-1ll is theoretically capable of 
describing volumes up to 2**32 blocks In size. In practice, 
a volume should be at least 100 blocks in sfze to be useful; 
current implementations of Files-11 will handle volumes up 
to 2**2h blocks. i | | | 


The logical. blocks of a volume must be randomly 


addressable. | The volume must also allow transfers of any 


length up to 65k bytes, in multiples of four bytes. When a 
transfer is longer than.512 bytes, consecutively numbered 
logical blocks are transfered until the byte count Is 
satisfied. In other words, the volume can be viewed as a 
partitioned array of bytes. It must allow reads and writes 
of arrays of any length less than 65k bytes, provided that 
they start on a logical block boundary and that the length 
[Is a multiple of four bytes. When only part of a block is 
written, the contents of the remalInder of that logical block 
will be undefined, 
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oe Volume Sets 


A volume set is a collection of related units that are 
normally treated as one logical device In the usual 
Operating system concept. Each unit contafins its own 
Flles-11 structure; however, files on the various units in 
a volume set may be referenced with a relative volume 

» which uniquely determines which unit in the set the 
File is located on. Other sections in this. specification 
will make occasional reference to volume sets and relative 
volume numbers where hooks for their Implementation exist. 
Since volume sets have not been implemented as yet, however, 
no complete specification Is provided here. 


3.0 Files 


Any data in a volume or volume set that is of any 


Interest (i.e., all blocks not available for allocation) fs 


contained in a file. A file ts an ordered set of 
b 


| » Where a virtual block jis. an array of 512 8 bit 
bytes. The virtual blocks of a file are consecutively 
numbered from 1 to n, where n blocks have been allocated to 
the file. The number assigned to a virtual block fs. called 
(obviously) its yirtual block , or YBN. Each virtual 
block is mapped to a unique logical block tn the volume set 
by Files-1l. Virtual blocks may be processed in the same 
manner as logical blocks. Any array of bytes less than 65k 
in length may be read or written, provided that the transfer — 
Starts on.a virtual block boundary and that its length Is a 
multiple of four. — | 7 


Sel File ID 


Each file In a volume set is uniquely identified by a 


File ID. A File ID ts a binary value consisting of &8 bits 


(3 PDP-11 words). It Is supplied by the file system when 
the file fs created, and must be supplied by the user 
whenever -he wishes to reference a particular file. 


The three words of the File ID are used as follows: 
Word 1 ~~ File Number 


Locates the file within a particular unit of the 
volume set. File numbers must lie in the range i 
through 65535. The set of file numbers on a unit 
is moderately (but not totally) dense; at any 
instant In time a flle number uniquely Identifies 
one file within that unlt. = , ; 
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Word 2 File Sequence Number 


Identifies the current use of an individual file 
number on a unit. File numbers are re-used; when 
a File is deleted its file number becomes 
available for future use for some other file. 
Fach time a file number is re-used, a different 
File sequence number is assigned to distinguish 
the uses of that file number. The file sequence 
number |s essential since it is perfectly ‘legal 
for users to remember and attempt to use a File ID 
long after that filie has been deleted. : | 


Word 3. Relative Volume Number | 
Identifies which unit of a volume set the file is 
located on. Volume sets are at present not 
implemented: the only legal value for the 
relative volume number In any context is zero. 

3.2 _ File Header _ “a | | 

Each file on a Files-11 volume Is described by a file 


beader. The file header is a block that contains all the 


information necessary to access the file. It is not part of 
the file; rather, it Is contained in the volume's index 
File. (The index file is described In section 5.1). The 
header block is organized into four areas, of which the 


first three are variable in size. 


3.2.1 Header Area 


~The information in the header area permits the 
File system to verify that this block Is in fact a 
file header and, in particular, is the header 
being sought by. the user. It contains the file 
number and file sequence number of the file, as 
well as Its ownership and protection codes. This 
area also contains offsets to the other areas of 
the file header, thus defining their size. 
Finally, the header area contains a user attribute 
area, which may be used by the user to store a 
limited amount of data describing the file. 


3.2.2 Ident Area 


The [dent area of a File header -contaltns 
identification and accounting data about the file. 
Stored here are the primary name of the file, its 
creation date and time, revision count, date, and 
time, and expiration date. 3 | 
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54265 ' Map Area 


The map area describes the mapping of virtual — 
blocks of the file to the logical blocks of the 
volume. The mapping data consists of a list of 
pol ; Each retrieval polnter 
describes one logically contiguous segment of the 
file. The map area also contains the linkage to 
the next extension header of the file, if such 
exists. | 


3.2.4 End Checksum 


The last two bytes of the fille header contain a 16 
bit additive checksum of the remaining 255 words 

of the file header. The checksum Is used to help 

verify that the block is in fact a flle header. 


3.8 7 S Exbens ion Headers 


Since .the file header is of Fixed sfze, it Is 
Inevitable that for some files the mapping Information wi.11 
not fit Inthe allocated space. A file with a large amount 
of mapping data is therefore represented with a chain of 
file headers. Each header maps a consecutive set of virtual 
blocks; the extenston linkage In the map area lYinks the 
headers together In order of. ascending virtual block 
numbers. | : | | 


Multiple headers are also needed for files that span 
units in a volume set. A header may only map logical blocks 
located on its unit; therefore a multIi-volume file Is 
represented by headers on all units that contain portions of 
that fille.  - 


3.4 File Header - Detailed Description © see I/o operations 
MAO WULA | 
This section describes fin detail the items contained in 
the file header. Each Item is identified by a symbol which 
represents the offset address of that item within its area 
in the file header. Any item may be located in the fille 
header by locating the area to which it. belongs and then 
adding the value of Its offset address. Users who concern 
themselves with the contents of file headers are strongly 
urged to use the offset symbols. The symbols may be defined 
in assembly language programs by calling and invoking the 
macro FHDOF$, which may be found In the macro library of any 
System that supports Files-11. Aiternatively, one may find 
the macro in the file FIIMAC.MAC, which may be obtained from 
the author. | 
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Header Area Description 


header area of the file header always starts at 


lt contains the basic information needed for 


the validity of accesses to the file. 
H.IDOF 1 Byte Ident Area Offset 


This byte contains the number of -16— bit dard: 
between the start of the file header and the start 


of the Ident area. It defines the location of the 
ident area and the size of the header area. 


H. MPOF 1 Byte Map Area Offset 

This byte contains the number of 16 bit words 
between the start of the file header and the start. 
of the map area. It defines the location of the 
map area and, together with H.IDOF, the size of 
the Ident area. | 

H.FNUM = 2 “Bytes File joker 

This word contains the file number of the file. 


H.FSEQ 2 Bytes File Sequence Number | 


| This word contains the file sequence number of the 


file. 
H.FLEV 2 Bytes File Structure Level 


The file - structure: level Is used to identify. 
different versions of Files-11 as they affect the 
Structure of the file header. . This permits 
upwards compatibility of file structures as 


_Files-11 evolves, in that the structure level word 


identifies the version of Files-11 that created 
this particular file. This document describes 
version 1 of Files-11; the only legal contents 
For H.FLEV is 401 octal. | 


H.FOWN 2 Bytes File Owner UIC 
H.PROG = H.FOWN+0 Programmer (Member) Number 
H.PROJ = H.FOWN+1 Project eoroen) Number 

This word contains the binary user identification 
code (UIC) of the owner of the file. The file 
owner is usually (but not necessarily) the ‘creator 
of the file. 
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3.4.1.7 


H.FPRO 2 Bytes File Protection Code 


This word controls what access all users in the 
System may have to the file. Accessors of a file 
are categorized according to the. relationship 
between the UIC of the accessor and the UIC of the 
owner of the file. Each category is controlled by 
a four bit field in the protection word. The 


category of the accessor is selected as Follows: 


System Bits 0 - 3 


The accessor is subject to system 

bo protection if the project number of the — 

| UIC under which: he fs running fis 10 
Octal or less. 


Owner Bits & - 7 


The. accessor is subject to owner. 
protection if the UIC under which he is 
running exactly matches the file owner 
UIC. | 


Group © Bits 8 - 11 


The accessor jis subject to group 
protection if the project number of his 
UIC matches the project number of the 
file owner UIC. 4 


World Bits 12-15 


The accessor is subject to world 
protection if he does not fit into any 
of the above categories. | - 


Four types of access intents are defined In 
Files-ll: read, write, extend, and delete. Each 
four bit field in the protection word is bit. 
encoded to permit or deny any combination of the 
four types of access to that category of 
accessors, setting a bit denies that type of 
access to that category. The bits are defined as 


follows (these values apply to a right-justified 


protection field): 


FP.RDV Deny read access 
FP.WRV Deny write access 
FP.EXT Deny extend access 


FP.DEL Deny delete access 
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54.1.8 


34.1.9 


When a user attempts to access a file, protection 


checks are performed tn all the categories to 
which he Its eligible, in the order system - owner 
~ §Foup - world. The user is granted access to 
the file if any of the categories to which he fs 
eligible grants him access. | | 7 


H.FCHA 2 Bytes File Charactertstics 
H.UCHA H.FCHA+0 User Controlled Char. 
H.SCHA H.FCHA+1 System Controlled Char. 


The user controlled characteristics byte contains 
the following flag bits: a ee 


UC.CON Set if the file Is logically : 
l.e., If for all virtual blocks in the 
File, virtual block i maps to logical 
block k+f on one unit for some constant 
k. This bit may be implicitly set or 
Cleared by file system operations that 


allocate space to the file; the user | 


may only clear it explicitly. 


UC.DLK. set if the file is deaccess-locked. 
This bit is used as- a flag warning that 
the file was not properly closed and may 
contain inconsistent data. Access to 
the file is denled {ff this bit is set. 


The system controlled | characteristics byte 


contains the Following flag bits: 


SC ..MDL Set if the flle is marked for delete. 
a If this bit is set, further accesses to 
the fiie are denied, and the file will 


be physically deleted when no users are ~ 


accessing it. — 


SC .BAD Set if there is a bad data block in the 


File. This bit Is as yet unImplemented. 
It is Intended for dynamic bad block 
handling. _ 


H.UFAT 32 Bytes User Attribute Area — 


This area is Intended for the storage of a limited 
quantity of “user file attributes", i.e., any data 
the user deems useful for processing the fille that 
is not part of the file itself. An example of the 
use of the user attribute area fs presented in 
section 6.1 (FCS File Format). | | 


—. 
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3.4.1.10 S HDHD 46 Bytes Size of Header Area 


This symbol represents the total sitze of the 
header area containing all of the above entries. 


5.4.2 Ident Area Description | 


The ident area of the file header begins at the word 
Indicated by H.IDOF. It contains Identification and 
accounting data about the file. | 


3.4.2.1 %I.FNAM 6 Bytes File Name 


These three words contain the name of the file, 
packed three Radix-50 characters to the word, 
_ This name usually, but not necessarily, 
corresponds to the name of the file's primary 
directory entry. : . 


See lezZ l.FTYP 2 Bytes File Type 


This word contains the type of the file in the 
form of three Radix-50 characters. | 


54.2.3 |.FVER 2 Bytes . Version Number 


This word contains the version number of the file 
in binary form. | | 


34.2.4 [.RVNO 2 Bytes Revision Number 
| This word contains the revision count of the file. 


The revision count is the number of times the file 
has been accessed for write. 


3.4.2.5 ~ I.RVDT ‘7 Bytes | Revision Date 


The revision date is the date on which the file 
was last deaccessed after being accessed for 
write. It is stored in ASCII in the — form 
"DDMMMYY", where DD Is two digits representing the 
day of the month, MMM is three characters 
representing the month, and YY is the last two 
digits of the year. 


34.2.6 [.RVTI 6 Bytes Revision Time 


The revision time is the time of day on which the 
file was last deaccessed after.being accessed for 
write. It is stored tn ASCII in the format 
"HHMMSS", where HH is the hour, MM is the minute, 
and SS is the second. i | 
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P-4-2.7 1.CRDT 7 Bytes Creation Date 


These seven bytes contain the date on which the 


File was created. The format is the same as that 


of the revision date above. 
3.4.2.8 [.CRT!.- 6 Bytes Creation Time 


These six bytes contain the time of day at. whtch 
the file was created. The format Is the same as 
_ that of the revision time above. | . uw 


‘3.4.2.9 1.EXDT 7 - Bytes Expiration Date 


These seven bytes contain the date on which the 


file becomes eligible to be deleted. The format — 
is the same as that of the revision and creation , 


dates above, | 
5o4.2.10 - ‘1 Byte (unused) | 


This unused byte is Present to round up the size 
if the ident area to a word boundary. | 


3-4.2.11 S.IDHD 46 Bytes Size of Ident Area 


This symbol represents the size of the ident: area 


containing all of the above entries. 


Seta 5 Map. Area Description 


The map area of the file header starts at the word 
indicated by H.MPOF. it contains the information necessary 
to map the virtual blocks of the file to the logical blocks 
of the volume. 7 - | : 7 | 


34.3.1 -M.ESQN lL Byte Extension Segment Number 


This byte contains the value n, where this header 
Is the ntlth header of the file; t.e., headers of 
a file are numbered sequentially starting with 0. 


| a re M.ERVN 1 Byte Extension Relative Volume No. 


This byte ‘contatns the relative volume number of 
the unit in the volume set that contains the next 
sequential extension header for this file. If 
there is no extension header, or if the extension 
header is located on the sa @ unit as this header, 
this byte contains 0. | 


{ 


ey 


bSeperany 


eeemen’ 


544.5.3 


304.35.4 


3.86365 
3.4.3.6 


324.3.7 : 


=, 3.4.3.8 


3.4.3.9 


Files-11 On-Disk Structure | : ‘Page 1] 


MJ EFNU 2 Bytes Extension File Number 


This word contains the file number of the next 
sequential extension header for this file. If 
there is no extension header, this word contains 
0. | | 


M.EFSQ 2 Bytes Extension Fite Sequence Number 


This word contains the file sequence number of the . 
next sequential extensfon header for this file, 
If there is no extension header, this = word 
contains 0. a . | 


M.CTSZ 1 Byte Block Count Field Size. 


This byte contains a count of the number of bytes 
used to represent the count field in the retrieval 
pointers in the map area. The retrieval pointer 
Format is described In section 3.4.3.9 below. 


M.LBSZ = Byte LBN Fleld Size 


This byte contains a count of the number of bytes 


used -to represent the logical block number fleld 
in the retrieval pointers in the map area. The 
contents of M.CTSZ and M.LBSZ must add up to an 
even number. | 


M.USE | 1 Byte Map Words In Use 

This byte contains a count of the number of words 
in the map. area that are Presently occupied by 
retrieval pointers. an 


M.MAX 1 Byte . Map Words Available 


This byte contains the total number of words 


available for retrieval pointers in the map area. 
M.RTRV variable Retrieval Pointers | 


This area contains the retrieval pointers that 
actually map the virtual blocks of the file to the 
logical blocks of the volume. Each retrieval 
pointer describes a consecutively numbered group 
of logical blocks which fs part of the file, The 
count Field contains the’ binary value nto 
represent a group of ntl tlogical blocks. The 
logical block number fleld contains the logical 
block number of the first. logical block In the 


group. Thus each retrieval potnter maps virtual 


blocks j through j+#n into. logical blocks k through 
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k+n, respectively, where j is the total number 
plus one of virtual blocks represented by al] 


preceding 


retrieval pointers In this and all 


preceding headers of the file, n Is the value 


contained 


in the count field, and k is the value 


contained In the logical block number field. 


Although the data in the map area provides for 
arbitrarily extensible retrieval pointer formats,. 
Files-1l1 has defined only three. Of these, only 


the first Is currently Implemented; the other two -_ 
are presented out of historical interest and 


because they may be resurrected in the future. 


Format 1: 


M.CTSZ 
M.LBSZ 


1 
3 


The total retrieval pointer length Is 
four bytes. Byte 1 contains the high 


order bits of the 2h bit LBN. Byte 2 


Format 2: 


Format 3: 


contains the count field, and bytes 3 


and & contain. the ioe 16 bits of the 


LBN. 

| momen nn en | omen enn nme 
| Count. | High | 
peSeaesa—n= |- = 
i Low Order ‘LBN ] 
 Rebeheatetetetetetatetetetnttteteteten | 
M.CTSZ = 2 

M.LBSZ = 2 


The total retrieval pointer length is 
four bytes. The first word contains a 


16 bit count field and the second word 


contains a 16 bit LBN field. 


[ Count i 
pesderetenae-seescse<s | 
| LBN | 
[Resnbaterenesssteseos | 
M.CTSZ = 2 
M.LBSZ = & 


The total retrieval pointer length is 
six bytes. The first word contains a 16 


bit count field and the second and third. 


words contain a 32 bit LBN field. 


a 
~e. 


~~ ao 


524.3.10 


3.4.4 
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S.MPHD 10 Bytes Size of Map Area 


This symbol represents the size of the map area, 
not. including the space used for the retrieval 


pointers. _ 


End Checksum Description 


The header check sum occupies the last two bytes of the 
file header. It is verified every time a header Is read, 
and is recomputed every time a header is written. 


3.4.b.1 


H.CKSM 2 Bytes Block Checksum 


This word Is a simple. additive checksum of al} 
other words in the block. -!t is computed by the . 
Following PDP-11 routine or its equivalent: 


MOV | Header-address,R0 
CLR RL. | 
— MOV #255.,R2 
10$3 . ADD | (RO)+,R1 
| SOB R2,10$ 


MOV R1, (RO) 
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H.FCHA 
H.UCHA 


H.UFAT 


~ §.HDHD 


1. FNAM 


[.FTYP 
|. FVER 


|. RVNO 
i. RVDT 


letatetatatatatetatatetasteptetatetenetateneeteireteitnmeatnn == | 
| File Protection { 
| ------------------- | ----2-------------- | 
| oh dal Char. |. User Char. i 
latatadatetetetatennteeetatetatatete ecatataterenetatatetatetatratatens | 
| | 
| _ | 
i | i 
| | User Attrtbute Area | ee | 
a | | ~ lo. 
| | 
| | 
| nanan anne enn n nnn anna nnn a nnn nn nn een sna | 
[Re Saennecneseetaatcersesseessseeetan = | 
| | 
|-- , =| 
| File Name | 
[== a=) 
| { 
[naam mene wren annem nnn nnn nnn ween nen enn =| 
| Fille Type | 
Tetatadatatetatatetatatatetatatadeatetanetateserenetateteteterateratateraans | 
| Version Number | 
[eT eater SRS Sas eee Sess s = S Sess 54s SSS = | 
| Revision Number | 
[Pr Seni Ses sSsSss SoS Ses Hoes es=SSSssess> | 
| | 
|-- =| 
| Revision Date | 
[oe == 
| | 
| | 
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4.0 Directories 


Files-11 provides directories to allow the organization 
of files in a meaningful Way. While the File ID ts 
sufficient to locate a file uniquely on a volume set, it Is 
hardly mnemonic. Dtrectories are files whose sole function 
Is to associate file name strings with Flle ID's, | 


kel Directory Helrarchles 


Since directories are files with no special attributes, 
directories may list files that are In turn directories. 


Thus the user may construct directory hetrarchies of 
arbitrary depth and complexity to structure his files as he 


pleases. a 


ie | User File Directories 


Current Implementations of Files-11 all support a two 
level directory helrarchy which Is tied In with the user 
identification mechanism of the operating system. Each UIC 
is associated with a user file directory (UFD). References 


‘to files that do. not specify a directory are generally. 
defaulted to the UFD assoclated with the-user's UIC. All 


UFD's are listed In the volume's MFD under a file name 
constructed from the UIC. A UIC of (n,m) assoclates with a 
directory name of “annmmm.DIR;1", where nnn and mmm are n 
' and m_= padded out to three digits each with leading zeroes. 
' Note that all number conversions are done in octal. | | 


Two points should be noted here. The UFD structure 


described here Is not intrinsically part of the Files-ll 
on-disk structure; rather, it Is a convenient cataloging 


System applied by various operating systems. Also, there [5 


no hard and fast relationship between the owner UIC of a 
file and’ the UFD in which it fs listed. Generally, they 
will correspond, but not necessarily... | | | | 


h.2 | Directory Structure 


A directory Is a file consisting of 16 byte records. 
It Is structured as an FCS fixed length record file, with no 
carriage control attributes (see section 6 for a description 
of FCS filles). Each record [is a directory entry. The 
entries are not required to be ordered, or densely. packed, 
nor do they have any other relationship to each other, 
except that no two entries In one directory may contain. the 
Same name, type, and verslon. Each entry contains the 
Following: | 


ew 


— 
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File ID. The three word binary File ID of the file that - 
this directory entry represents. If the file 
number portion of the File ID field js zero, then 
this record is empty and may be used for a new 
directory entry. 


Name The name of the file may be up to 9 characters. 


Ht is stored as three words, each containing three 
Radix-50 packed characters. © 


Type The type of the file (also historically referred 
to as the extension) may be up to three 
characters. It Is stored as one word of Radix-50 
packed characters. 7 


Version The version number of the file is stored in binary 
in one word. Oe 


| Version [ 


4.3 | Directory Protection 


Since directories are files with no special 
characteristics, they may be accessed like all other files, 
and are subject to the same protection mechanism. However, 
implementations of Files-1] support three special functions 
for the management of directories, namely FIND, REMOVE, and 
ENTER. A user performing such a directory operation must 
have the following privileges to .be allowed the various 
functions: i 


FIND: READ | 
REMOVE: READ, WRITE 
ENTER: READ, WRITE, EXTEND 
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5.0 Known Files 


Clearly any file system must maintain some data 
Structure on the medium which ts used to control the file 
organization. In Files-11 this data js kept in five files. 
These files are created when a new volume is initialized. 
They are unique in that their Fille ID's are known constants. 
These five Files have the following uses: 


File 1D 1,1,0 Is the index file. The index file ts the 
root of the entire Files-11 structure. It contains the 


volume's bootstrap block and the home block, which Its used. 


to identify the volume and locate the rest of the file 
Structure. The index file also contains all of the file 
headers for the volume, and a bitmap to control the 
allocation of file headers. oy ae 


File ID 2,2,0 Is the storage bitmap fille. It Is used» 


_ to control the allocation of logical blocks on the volume. 


File 1D 3,3,0 Is the bad block file. It Is a file. 


containing all of the known bad blocks on the volume. 


File 1D 4,4,0 Is the volume master flle directory (or 


MED). It forms the root of the volume's directory 
Structure. The MFD lists the five known files, all first 


‘level user directories, ‘and whatever other files the user. 


chooses to enter. 


File ID 5,5,0 Is the system core image file. Its use. 


Is operating system dependent; its basic purpose Is to 
provide a file of known File ID for the use of the operating 
system. : _ re 2 | 

ye a Index File 


The Index file fs Flle 1D 1,1,0. It Is listed In the 
MFD as INDEXF.SYS;1. The Index file is. the root of the 
Files-1l structure In that it provides the means for 
identification and Initial access to a Files-11 volume, and 
contains the access data for all files on the volume 
(Including itself). - 


ares Gare Bootstrap Block 

Virtual block l of the Index file Is the volume's boet 
block. It Is always mapped to logical block 0 of the 
volume. If the volume {ts the system device of an operating 
system, the boot block contains’ an operating system 


dependent program which reads. the Operating system tinto 
memory when the boot block is read and executed by a 


? , 
Nee 


me 
fe 
f 4 ; 
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| machine's hardware bootstrap. If the volume is not a system 


device, the boot block contains a small program that outputs 
a message on the system console to inform the operator to 
that effect. | 


5.1.2 Home Block 


Virtual block 2 of the index file is the volume's: home 
block. The logical block containing the home block is the 
First good block on the volume out of the sequence 1, 256, 
2912, 768, 102%, 1280, .... 256*n. The purpose of the home , 
biock is to identify the volume as Files-11, establish the 
specific identity of the volume, and serve as the ground 
zero entry point into the volume's file structure. The home 
block is recognized as a home block by the presence of 
checksums in known places and by the presence of predictable 
values in certain locations. | 


{tems contained jacihehere block are identified by 
symbolic offsets in the same manner as items in the file 
header. The symbols may be defined tn assembly language 
programs by calling and invoking the macro HMBOF$, which may 
be found in the macro library of any system that supports 


Files-11. Alternatively, one may find the macro in the File 


F11MAC.MAC, which is available. From the author. . 
Se be 2 el H.IBSZ  =—s._-o2 Bytes ‘Index File Bitmap Size. 


This 16 bit word contains the number of blocks 
that make up the index file bitmap. (The index 

File bitmap is discussed in section 5.1.3.) This 

value must be non-zero for a valid home block. 


5.1.2.2 H.IBLB 4 Bytes Index File Bitmap LBN 


This double word contains’ the starting feeieat 
block address of the index file bitmap. Once the 
home. block of a volume has been found, it is this 
value that provides access to the rest of the 
index file and to the volume. The LBN is stored 


with the high order In the first 16 bits, followed 


by -the low order. portion. This value: must be 
non-zero for a valid home block. 


5.1.2.3 H.FMAX 2 Bytes Maximum Number of Files 


This word contains the maximum number of files 
that may be present on the volume at any time. 
This value must be non-zero for a valid home 
block. : 
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5.1.2.4 


501.265 


5.1.2.6 


5.1.2.7 


5.1.2.8, 
5512259" 


5-1.2.10 


H.SBCL 2 Bytes Storage Bitmap Cluster Factor 


This word contains the cluster factor used in the 
storage bitmap file. The cluster factor is the 
number of biocks represented by each bit in the 
storage bitmap. Volume clustering is not 
implemented at present; the only legal value for 
this item is 1. 


H. DVTY 2 Bytes ‘Disk Device Type 


This-word is an index Identifying the type of disk 
that contains this volume. It Is currently not 


used and always contains 0. 


.. H.VLEV 2 Bytes Volume Structure Level 


This word. identifies the volume' s structure level. 


Like the file structure level, this word 
identifies the version of Files-1ll whieh created. 


this volume and permits upwards compatibility of 
media as Flles-11 evolves. The volume structure 
level is affected by all portions of the Files-1li 


structure except the contents of the file header. — 
This document describes Files-11 version 1; the 
only legal value for the structure level is 401. 


octal. 


H.VNAM. 12 Bytes- Volume Name 


This area contains the varune label as an ASCI1. 


string. It is padded out to 12 bytes with nulls. 
The volume label Is used to identify individual 
Files-11 volumes. | : 


- 4 Bytes Not Used ~~ | 
H.VOWN 2 Bytes Volume Owner UIC 
This word contains the binary UIC of the owner of 
the volume. The format is the same as that of the 
file owner UIC stored In the file header. 
H.VPRO 2 Bytes Volume Protection Code 
This word contains the protection code for the 


entire volume. Its contents are coded in the same 
manner as the file protection code stored In the 


fille header, and It is Interpreted fn the same way 


in conjunction with the volume owner UIC. Al} 
operations on all files on the volume must pass 
botn the volume and the file protection check to 


be permitted. (Refer to the discussion on File. 


a, 


“33 a, 
ss 
( 
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5.1.2.11 


5.1.2.12 


Bete eas 


5.1.2.14 


2e1.2.15 


321.2.16 


Protection In section 3.4.1.7). 
H.VCHA 2 Bytes Volume Characteristics 


This word contains bits which provide additional 
control over access to the volume. The Following 
bits are defined: | 


CH.NDC Set if device control functions are not 
permitted on this. volume. Device 
control functions are those which can 
threaten the Integrity of the volume, 
such as direct reading and writing of 
logical blocks, etc. 


~CH.NAT Set If the volume may not be attached, 


i.e., reserved for the sole use by one 


H.FPRO 2 Bytes Default File Protection 


This word contains the File protection. that wil} 


be assigned to all files created on this volume [If 


no file protection is specified by the user. 
* - 6 Bytes Not Used 
H.WISZ 1 Byte Cefault Window Size 


This byte contains the number of retrieval 
pointers that will be used for the "window" (Cin 
core file access data) when files are accessed on 
the volume, If not otherwise specified by the 
accessor. : 


H.FIEX 1 Byte Default File Extend 


‘This. byte contains the number of blocks that wil] 


be allocated to a file when a user extends’ the 
File and asks for the System default value for 
allocation. — : 


H.LRUC 1 Byte Directory Pre-access Limit 


This byte contains a count of the number of 
directories to be stored in the file system's 
directory access cache. More generally, it is an 
estimate of the number of concurrent users of the 
volume and its use may be generalized in the 
Future. _ Oo 
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5.1.2.17 


5.1.2.18 


5.1.2.19 


9eL.2.20 


92.1.2.21 


5.1.2.22 


5.1.2.23 


5.1.2.24 


= 11 Bytes Not Used 


H.CHKI1 2 Bytes First Checksum 


This word is an additive checksum of all entries 


preceding in the home block (ice., all those 
listed above). It is computed by the same sort of 
algorithm as the file header checksum (see section 
re | ee ee et | 


H.VDAT 14 Bytes Volume Creation Date 


This area contains the date and time that the 


volume was’ initialized. It is in the format 
"DDMMMYYHHMMSS", followed followed by a single 


null. (The same format is used in the ident area 
of the file header, section 3.4.2). | 


- 398 Bytes Not Used 


This area is reserved ‘for the relative volume - 


table for volume sets. | | 


H.INDN 12 Bytes Volume Name 


This area contains another copy of the ASCII 


volume label. lt is padded out to 12 bytes with 
spaces. It is placed here in accordance with the 
proposed volume identification standard. 3 


H.INDO © 12 Bytes Volume Owner 
This area contains an. ASCII expansion. of the 


volume owner UIC in the form "{proj,prog)". Both 
numbers are expressed in decimal and. are padded to 


three digits with leading zeroes. The area ‘is 
padded out to 12 bytes with trailing spaces. [It 


is placed here in accordance with = the proposed 
volume identification standard. | 


H. INDE 12 Bytes Format Type 


This field contains the ASCII string "DECFILE1L1A" 
padded out to 12 bytes with spaces. It identifies 
the volume as being of Files-11 format. It is 
placed here In accordance with the proposed volume 
identification standard. 


- 2 Bytes Not Used 


7” 
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- 54142625 H.CHK2 2 Bytes Second Checksum 


This word is the last word of the home block. It 
contains an additive checksum of the preceding 255 
words of the home block, computed according to the 
algorithm listed in section 3.4.4.1. 


tena! 
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5.1.2.A 


H.FIEX 


Home Block Layout 


Index File | ) | 
Bitmap LBN : | To 
Maximum Nunber oF Files 
“Storage Bitmap Cluster Factor | 
"Disk Device Type 7 
___Yolume Structure Level a ! 
Volume Name 7 
| | 
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_ Volume Protection 
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___Default File Protection oe | 
— SS OR DS OD Oe ae a eee Oe ene OD aD Om me we cae me me ome nD ee ene ene oe ee | 
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| ~=----------------- | 
File Extend | Def. Window Size | 

| 

| 


10 OO Om Om om we em me om me ce me ew ow) OS. ae a um om | 
Directory Limit | 
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—H.CHK1 


H.VDAT 


H.INDN 


H. INDO 
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‘ 
| 
(== aa | 
— | 
= re 
— Format Type | 
|-- | 
| | 
[== sie 
_ | 
[=> == 
| | 
| moana nnn-n-------------------------- ~~... 
| (not used) | 
| pane n enna nn --- ~~ == | | | 
| Second Checksum | H.CHK2 
| ee Oe ne ae ae me Om oem eae ae ae ome ne ee oe ee oe ee eee oe ene ees | 
5.1.3 Index File Bitmap | - | 
The index file bitmap is used to control the allocation 


of file numbers’ (and hence file headers). It is simply a 
bit string of length n, where n is the maximum number — of 
files permitted on the volume (contained in offset H.FMAX in 
the home block). The bitmap spans over as many blocks as Is 
necessary to hold it, i.e., max number of files divided by 


4096 and rounded up... The number of blocks in the bitmap is | 


contained in offset H.IBSZ of the home block. | 


The bits fn the index file. bitmap are numbered 
sequentially from 0 to n-1 in the obvious manner, i.e., from 
right to left in each byte, and in order of increasing byte 
address. Bit j Is used to represent file number j+l: Uf 
the bit Is 1, then that file number is in use; if the bit 
is 0, then that file number is -not [In use and may be 
assigned to a newly created file. | 


The index file bitmap starts at virtual block 3 of the 
index file and continues through VBN 2+m, where m is the 
number of blocks in the bitmap. It is located at the 
logical block indicated by offset H.IBLB in the home block. 


5.1.4 | File Headers 


The rest of the Index file contains all the file 
headers for the volume. The first 16 file headers (for file 


< 
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numbers 1 to 16) are logically contiguous with the index 
File bitmap to facilitate their location; the rest may be 
allocated wherever the file system sees fit. Thus the first 
16 file headers may be located from data in the home block 
(H.IBSZ and H.IBLB) while the rest must be located» through 
the mapping data In the index file header. The file header 
for file number n is located at virtual block 2+m+n (where m 
is the number of blocks In the Index file bitmap). 


5.2 Storage Bitmap File 


The storage bitmap file is Flle ID 2,2,0. It is listed 


tn the MFD as BITMAP.SYS;1. The storage bitmap is used to 
control the available space. on a unit. lt consists of a 


Storage control block which contains summary information 


about the unit, and the bitmap itself which lists the | 


availablilty of tndividual blocks. 


5.2.1 Storage Control Block 


Virtual block 1 of the storage bitmap is the Storage. 


control biock. It contains summary information intended to 


optimize allocation of space on the unit. The following 
items are in thé storage contro} block: - Ba | 


‘(3 bytes) Not used (zero) 


(1 byte) Number of storage bitmap blocks 
(2 bytes) Number of free blocks in lst bitmap block 
(2 bytes) Free block pointer in Ist bitmap block 


€2 bytes) Number of free blocks in nth bitmap block — 


(2 bytes) Free block pointer in nth bitmap block 


(4 bytes) Size of the unit in logical blocks 


Note: Current implementations of Files-11 do not correctly 
initialize the word pairs containing number of free blocks 
and free block pointer for each bitmap block, nor are these 
values maintained as space is allocated and freed on the 
unit. They are therefore’ best looked upon as 2n garbage 
words and should not be used by future implementations of 
Files-11 until the disk structure is formally updated. 


Slee Storage Bitmap 
Virtual blocks 2 through n+1 are the storage bitmap 


itself. lt is best viewed as a bit string of length m, 
numbered from 0 to m-1, where m is the total number of 


logical blocks on the unit rounded up to the next multiple 
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of 4096. The bits are addressed in the usual manner (packed 
right to left in sequentially numbered bytes). Since each 
virtual block holds 4096 bits, n blocks, where n = m/&096, 
are used to hold the bitmap. Bit j of the bitmap represents 
logical block j of the volume; if the bit is set, the block 
is free; if clear, the block is allocated. Clearly the 
last k bits of the bitmap are always clear, where k jis the 
difference between the true size of the volume and m, the 
length of the bitmap. : —— 


5.3. Bad Block File 


| -The bad block file is File 1D 3,3,0. It is listed in 
the MFD as BADBLK.SYS;1... The bad block file is simply a 
File containing all of the known bad blocks on the volume. 


563.1 Bad Block Descriptor 


Virtual block 1 of the bad block file is the bad block 
descriptor for the volume. It is always located on the last 
good block of the volume. This block may contain a listing 
of the bad blocks on the volume produced by a bad block scan 
Program or diagnostic. The format of the bad block data .is 
identical to the map area of a file header, except that the 
first four entries (M.ESQN, M.ERVN, M.EFNU, and M.EFSQ) are 
not present. The last word of the block contains the usual 
additive checksum. (See section 3.4.3 for a description of 
the map area.) This block is included in the bad block file 
to save the data it contains for future re-initialization of 
the volume. | _— 


Bad Block Descriptor Layout 


a ie ae ask a wo enn === | 
Count Field Size 


| 

| 

| 

| 

| 

| 

Retrieval Pointers : | 
| 

| 

| 
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5.4 Master File Directory 


: The master file directory is File ID 44,0. It Is 
listed In the MFD (itself) as OOO000.DER;1. The MFD is the 
root of the volume's directory structure. [It lists the five 
Known files, plus whatever the user chooses to enter. In 
the two level UFD structure described in section 4.1.1, the 


‘MED contains entries for all user file directories. 


5.5 Core Image File 


The core image file is Fille ID 5,5,0. It.is listed in 
the MFD as CORIMG.SYS;1. Its use is operating system 
dependent. In general, it provides a file of known Fille 1D 
for the use of the operating System, for use as a swap area, 
for example, or as a monitor overlay area, etc. 


6.0. FCS .File Structure | 
File Control Services (FCS) Is a user level interface 
to Files-11. Its. principal feature is a record contro} 


facility that allows sequential processing of variable 


length records and sequential and random access to fixed 


length record filles. FCS interfaces to the virtual block 


‘facility provided by the basic Files-11 structure. 


6.1 FCS File Attributes 


FCS stores attribute information about the file in the 
file's user attribute area (H.UFAT - see section 3.4.1.9). 
It uses only the first 7 words; the rest are ignored by 
FCS. The following items are contained In the attribute 
area; they are identified by the usual symbolic offsets 


(relative to the start of the attribute.area). The offsets _ 


may be defined In assembly language programs by calling . and 
Invoking the macro FDOFF$ DEF$L. Flag values and bits may 
be defined by calling and invoking the macro FCSBT$. These 
macros are in the system macro library of any operating 


System that supports Files-11. Alternatively, all these 


values are defined in the system object library of any 
system that supports Files-1ll, and may be obtained at link 
time. : 


6.1.1 F.RTYP 1 Byte Record Type | 
This byte Identifies which type of records are 


contalned in this file. The following two values 
are legal: a 
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R.FIX = Fixed length records. 
R.VAR Variable length records. 


F.RATT 1 Byte Record Attributes 


This byte contains. record attribute bits that 
control the handling of records under various. 


contexts. The following flag bits are defined: 


FD.FTN Use Fortran. carriage control tf set. 
The first byte of each record js to be 


Interpreted as a Standard Fortran. 


Carriage control character when the 
record is copied to a carriage control 
device. | a a 


FD.CR Use implied carriage control If set. 


When the file is copied to a carriage 
control device, each record jis to be 


Preceded by a line feed and followed by 
a carriage return. Note that the FD.FTN 
and FD.CR bits are mutually exclusive. 


FD.BLK | Records do not cross block boundaries if 


set. Generally, there wil]. be dead 
Space at the end of each block; how 
this is handled is explained in the 
“description of record formats in section 
6.2. 7 


FARSIZ 2 Bytes Record Size 


‘In a fixed length record file, this word contains 


the size of the records in bytes. Ina variable 
length record file, this word contains the size in 
bytes of the longest record in the file. 


F.HIBK = & Bytes Highest VBN Allocated 

This 32 bit number is a count of the number of 
virtual blocks allocated to the file. Since this 
value is maintained by FCS, it is usually correct, 
but It is not guaranteed since FCS is a user level] 
package. . 

F.EFBK 4 Bytes End of File Block 


This 32 bit number is the VBN in which the end of 


file is located. Both F.HIBK and F.EFBK are 


Stored with the high order half in the first two 
bytes, followed by the low order half. 


on 
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6.1.6. F.FFBY 2 Bytes First Free Byte 


This word is a count of the number of bytes in use 
in the virtual block containing the end of file; 
f.e., it is the offset to the first byte of the 
file available for appending. Note that an end of 
file that falls on a block boundary. May be 
represented in either of two ways. If the file 
contains precisely n blocks, F.EFBK may contain n 
and F.FFBY will contain 912, or F.EFBK may contain 

n+l and F.FFBY will contain 0. | | 


Gsic7? * * SvPATT * Gu ‘Byres. €isc-c¢ Attribute Block 


This symbol represents the total number of bytes 
in the FCS file attribute block. 


6.1.A. FCS. File rr oe oe 
| ee cro------ | mone nee w----] os 
F.RATT  —s | Record Attr. | Record Type [ F.RTYP 
| ___ Record Size (aytes) | . reasiz, 
eee ee ee. 
; _ Allocated _ ; - 
_ . Mme F.EFBK 
ae  VBN ae 
. aaa F.FFBY 
poocs--- se Dee mPa e enak a ew mia Se ee S21 Se FATT 
- 6.2 Record Structure 


This section describes how records are packed in the 
virtual blocks of a= disk file. In general, FCS treats a 
disk file as a sequentially numbered array of bytes, 
Records are numbered consecutively starting with 1. 


OeZ2ek Fixed Length Records 


ina file consisting of fixed length records, the 
records are simply packed end to end with no additional 
control information. For direct access, the address of a 
record is computed as follows: | 
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record number 

record size (In bytes) 

byte address of record In file 

number of records per block 

VBN containing the start of the record 
byte offset within VBN 5 


Let: 


hot pou 


mle DQ Jeg 


(n-1)*k 
m/512+1 (truncated) 
2 


Then 


ome Line = 


m mod 51 


The previous discussion assumes that records cross block 


_boundarftes. (that fs, FD.BLK Is not set). . If records do not 


cross block boundaries, they are limited to 512 bytes, and 


the following equations apply (the variables are defined as 


above): | 
q = 512/k (truncated) 
J = (n-1)/q+l (truncated) 
i = ((n-1) mod q)*k 
6.2.2 Variable Length Records 


In as: file consisting of variable length records, 


records may be up to 32767 bytes In length. Each: record fs 


preceded by a two byte binary count of the “bytes in the 
record (the count does not Include itself). For example, a 
null record is represented by a single zero word. The byte 
count is always word aligned; [.e., if a record ends on an 
.odd byte boundary, It is padded with a stngle null. Ff 
records do not cross block boundaries (FD.BLK Is set), they 
are limited to a size of 510 bytes. A byte count of -1 is 


used as a flag to signal that there are no more records in a 
particular block. The remainder of that block is then dead. 


Space and the next record in the file Starts at the 
beginning of the next: block. a 7 


Loe 


